結合 Git Flow 的 GitHub Flow 工作流程：

以 Git Flow 為基礎，保留 Main 、Develop、Feature、Hotfix 四種分支（少了 Release），將專案放在 GitHub Repository，分支更動時，由開發人員將 Local Side 完成的程式碼 Commits 推到 Remote Side 相同名稱的分支上，發佈 Pull Request，並指派團隊 1 ~ 2 名成員進行 Code Review。

Workflow

四種 Branch

• main ：
  • 加上版號，為 Release 版。
  • 保持跟正式機同個版本。
• develop ：
  • 為測試版，新功能開發完後，會先併到 develop 進行測試。
• feature ：
  • 將從 develop 拉出分支，用於新功能開發、既有功能擴充或是較大的 bug 修復 。
  • 命名規則：feat/dev_${moduelName}_${functionName} 。
    • e.g., feat/dev_upManage_oDoc 管理模組-文件銜接管理(oDoc為該功能的.js名稱)。
• hotfix ：
  • 修復分支，從 main 拉出分支，當 main 上版後，hotfix 需刪除，再重新拉一個版本，待 main 要上新版本時，將這之前所有的 fix 分支都合併。
  • 命名規則：
    bug 1 fix_${moduelName}_${functionName}。
    bug 2 fix_${moduelName}_${functionName} 。
    • e.g., fix_upManage_upsCase 管理模組-點位案件管理功能(ups-up的stake相關的案件)。

操作流程

• Local Side
  • 開發新功能：從 develop 拉出新的分支，以功能特性命名。
    • feat/dev_${moduelName}_${functionName}。
    • 開發完成：push 到 Remote，GitHub 會自動在 Remote 創相同名字的分支。
  • 修復一個既有的(上線版)功能：從 main 拉出新的分支，以功能取名。
    • fix_${moduelName}_${functionName}1 。
    • fix_${moduelName}_${functionName}2。
    • fix_${moduelName}_${functionName}3。
    • 開發完成： 1、2、3 分別 push 到 Remote 的hotfix ，當 main 要上版時，將 hotfix 合併 main 。
• Remote Side (GitHub)
  • PR / Code Review：接收到從 Local push 上來的分支，需發 PR，請開發人員指定 Code Reviewer。
    • 發PR 時機：
      • dev_${moduelName}_${functionName} 併到 develop。
      • fix_${moduelName}_${functionName} 併到 hotfix 。
• 上線前：將 develop 、hotfix 併到 main 。
  • 分支併完需刪掉，避免忘記哪些已經合併到 main 。
  • main 加上 tag 。
    • tag 命名: 上線版YYYYMMDD, e.g., 上線版20240228 。